2021.6.24 星期四 16：21

扩展

modal层，service层

DAO层：
DAO层叫数据访问层，全称为data access object，属于一种比较底层，比较基础的操作，具体到对于某个表的增删改查，也就是说某个DAO一定是和数据库的某一张表一一对应的，其中封装了增删改查基本操作，建议DAO只做原子操作，增删改查。

Service层：
Service层叫服务层，被称为服务，粗略的理解就是对一个或多个DAO进行的再次封装，封装成一个服务，所以这里也就不会是一个原子操作了，需要事物控制。

Controler层：
Controler负责请求转发，接受页面过来的参数，传给Service处理，接到返回值，再传给页面。

总结：
个人理解DAO面向表，Service面向业务。后端开发时先数据库设计出所有表，然后对每一张表设计出DAO层，然后根据具体的业务逻辑进一步封装DAO层成一个Service层，对外提供成一个服务。

标准主流现在的编程方式都是采用MVC综合设计模式，MVC本身不属于设计模式的一种，它描述的是一种结构，最终目的达到解耦，
解耦说的意思是你更改某一层代码，不会影响我其他层代码，如果你会像spring这样的框架，你会了解面向接口编程，表示层调用控制层，控制层调用业务层，业务层调用数据访问层。
初期也许都是new对象去调用下一层，比如你在业务层new一个DAO类的对象，调用DAO类方法访问数据库，这样写是不对的，因为在业务层中是不应该含有具体对象，最多只能有引用，如果有具体对象存在，就耦合了。当那个对象不存在，我还要修改业务的代码，这不符合逻辑。好比主板上内存坏了，我换内存，没必要连主板一起换。我不用知道内存是哪家生产，不用知道多大容量，只要是内存都可以插上这个接口使用。这就是MVC的意义。

接下来说你感觉service的意义，其实因为你现在做东西分层次不是那么严格，在一个你们做东西业务本身也少，
举个最简单的例子，你做一个分页的功能，数据1000条，你20条在一个页，你可以把这个功能写成工具类封装起来，然后在业务层里调用这个封装的方法，这才是业务里真正干得事，只要没访问数据库的，都要在业务里写。
再有不明白的追问，这是经验问题，呵呵，其实以后你就会懂。只是刚开始写的代码都是有个请求，我就去数据库取，业务几乎没有。

dao层是和数据库打交道的逻辑层里面封装了数据库操作的一些基本方法。。
service层是业务层很可能你在注册一个用户的时候还需要往日志表里加一个日志，那么就在service对这个业务实现并对这个业务加上事务。。好处不言而喻了。。如果你在你的C层连续用UserDao LogDao 那万一某一步出错了。有可能造成User加进去 Log没加进去。

model层：就是对应的数据库表的实体类，即将现实对象抽象成类。
<!–
Dao层：是使用了Hibernate连接数据库、操作数据库（增删改查）和model层。

Service层：引用对应的Dao数据库操作，在这里可以编写自己需要的代码（比如简单的判断）。

Action层：引用对应的Service层，在这里结合Struts的配置文件，跳转到指定的页面，当然也能接受页面传递的请求数据，也可以做些计算处理。

以上的Hibernate，Struts，都需要注入到Spring的配置文件中，Spring把这些联系起来，成为一个整体。

一般java都是三层架构：数据访问层（dao）、业务逻辑层（biz 或者services）、界面层（ui） –>